Pepvoid Education Edition

Status: first Education preset drafted for review and ISO testing. It targets older school computers and uses Pepvoid’s tested XFCE desktop.

Purpose and first release boundary

Build an installable, classroom-ready workstation image for schools. Keep the first release focused on computers students and teachers use directly. A complete school server is a separate product: it needs network design, account provisioning, storage, backup, update operations, and ongoing support. Do not present a desktop ISO as a replacement for those services.

The provisional base is x86_64 glibc, the linux-lts kernel, XFCE on X11, and the established Pepvoid theme and installer. The LTS kernel is selected for the Education edition to favor a steadier kernel baseline and broad hardware compatibility; qualify device support against the actual school hardware before release. XFCE gives school users a familiar panel, application menu, and window behavior while remaining lighter than the Plasma desktop used by the Gaming edition. It is already configured and exercised in Pepvoid, which reduces the chance of adding a new desktop-specific problem to the school image. Use one desktop for the whole age range; organize applications and guidance by age and subject instead of making younger students learn a different desktop. LXQt remains a possible lower-resource alternative only if tests on representative old hardware show a useful improvement without making the interface less usable for students and teachers.

School deployment needs

Before building, record whether the image is for shared lab computers, assigned student laptops, or both; expected device age and RAM; school locale and languages; existing account, file, printer, and Wi-Fi systems; internet availability; and the people responsible for updates and support.

Design for a normal installed system with separate named accounts and standard permissions. A shared student account makes it difficult to protect work and attribute files. Use existing school LDAP/AD/FreeIPA only after testing the school’s actual service. The first image does not provision a domain, DHCP, network home directories, proxy, thin clients, or PXE deployment.

Do not claim that a general browser or DNS setting is a child-safe web filter. Any content filtering, classroom observation, remote control, camera/microphone access, and student-data retention must be selected and disclosed by the school under its own policy. No remote monitoring service should be enabled by default.

Protecting the system from accidental changes

Treat students as standard users. The account created by Calamares must not be in wheel or another group that grants administrative access, and it must not have a passwordless sudo or Polkit path to system changes. Keep package installation, drivers, users, services, firewall, boot settings, and system-wide desktop configuration behind a separate root credential set by the adult installing the school computer. Staff should not share this password with students or use the root account for ordinary desktop work. A teacher should be able to lock the student session before leaving the computer.

The Education preset now installs nftables and Void’s runit-nftables early-boot integration. Its host firewall drops unsolicited inbound and forwarded traffic by default, while allowing loopback, established replies, outbound connections, and ICMP/ICMPv6 needed for network operation. This keeps web access working while blocking new connections to local services. SSH, Avahi/mDNS, Samba, NFS, UFW, and the sudo binary are excluded from this edition unless deliberately reintroduced. Automatic printer discovery may therefore be unavailable; staff can configure a printer by address. Void’s handbook documents runit-nftables as the stage-one mechanism that restores /etc/nftables.conf before normal services start.

This needs an Education-specific installer configuration. The shared Calamares users.conf adds the created account to wheel by default, so the Education preset replaces it: the installed account is unprivileged, root gets a separate password, and graphical administrator prompts authenticate as root. No fixed administrator password is shipped. Keep this policy isolated to the Education preset so existing Pepvoid editions retain their current installer behavior. Hiding system tools from the student menu can reduce confusion, but permissions must enforce the restriction.

Keep system files root-owned and student settings confined to each home directory. Do not make the whole root filesystem immutable in the first release: that complicates updates and repair. For shared lab machines, offer an optional managed profile that restores selected desktop settings at logout or reboot, while preserving student work in named accounts or school storage. Never silently erase a student’s home directory. Document a recovery route: teacher account, offline guide, tested backup/restore process, and a known-good reinstall image. Protect firmware and boot-device settings at the school level; local account restrictions alone cannot protect a computer from someone who can boot external media.

For computers that will store sensitive school or student information, require full-disk encryption at installation and encrypted backups. Calamares currently allows automated LUKS partitioning, but this image’s GRUB, dracut, and Calamares combination still needs an end-to-end install/boot test before the Education ISO can claim that encrypted installs work reliably. The shared Calamares configuration currently selects LUKS1 for GRUB compatibility; do not switch formats or preselect encryption without testing unlock, updates, and recovery on both UEFI and BIOS systems. Unencrypted /boot also leaves a physical tampering risk; use firmware protections and controlled boot media. Do not put sensitive files on machines until the school has verified encryption at rest, recovery keys, and encrypted off-device backups. Full-disk encryption does not protect files while a session is unlocked or from malware running in that session.

The firewall is one layer, not a complete intrusion-prevention system. Before calling this edition suitable for public deployments, also test the default service list and listening ports, verify IPv4 and IPv6 behavior, establish a supported update and restore schedule, and consider AppArmor only after its profiles and boot integration have been tested with the desktop, printer, installer, and learning applications. Protect firmware setup with a staff-only password, disable external boot where practical, keep physical access controlled, and store encrypted backups separately from the computer.

Before calling the image ready, test from a student account that system-wide settings cannot be changed, package installation is denied, administrator authentication is required for maintenance, teacher tools still work, and student files survive logout, reboot, and recovery. Test every desktop action and Polkit prompt in XFCE rather than assuming menu hiding or one permission rule covers all system services.

Proposed software groups

Use an intentionally small core plus named subject groups so a school can choose what belongs on its machines.

Learning pathway

Approximate ages

Candidate applications

Delivery

Early years

3–6

GCompris, Tux Paint and stamps

GCompris in the core; Tux Paint in the younger-learner group

Primary

6–10

GCompris, Tux Paint, typing practice, LibreOffice basics, browser research

Core plus a small primary group; use large, clearly named XFCE menu sections

Lower secondary

10–14

LibreOffice, Anki, geometry/graphing, astronomy/geography, introductory coding

Add subject groups as needed; avoid presenting all tools to every student

Upper secondary

15–18

Python/JupyterLab, Maxima/wxMaxima, Octave, advanced office and note-taking

Optional subject packs; keep the heavier scientific stack off low-spec installations unless requested

Teachers

Adult

Classroom guides, printing, language/accessibility settings, optional authoring tools

Separate Teacher resources section; no remote monitoring or student tracking by default

The common classroom core should stay small: XFCE, Firefox, LibreOffice, PDF/archive tools, printer support, Portuguese and English language resources, and GCompris as the broad early-learning suite. Make other applications selectable in build-time groups called primary, lower-secondary, upper-secondary-science, computing, and teacher-tools. Where adding build-time selection is not yet supported, keep the list documented and omit unselected tools rather than installing the entire catalog.

The cached official x86_64 Void repository metadata was checked on 2026-10-20. It contains GCompris, Tux Paint, Tux Paint stamps, Tux Paint Config, Stellarium, Kig, KTouch, KTurtle, KmPlot, KStars, Marble, Anki, LibreOffice, Firefox, Klavaro, Gtypist, JupyterLab, Octave, Maxima, wxMaxima, Python NumPy/Matplotlib, and Xournal++. Recheck names, dependencies, and sizes immediately before building; this is a rolling distribution. Kalzium, KGeography, GeoGebra, Veyon, and Scratch were not found under those names in that repository snapshot.

Scratch is designed especially for ages 8–16, but the Flathub package is marked unverified and community-maintained, not an MIT-supported build. Do not bundle it until its source, update path, offline behavior, and school suitability are reviewed. GCompris is a native fit for younger learners: its official suite covers ages 2–10 and reading, arithmetic, science, geography, and computer basics. Tux Paint targets ages 3–12. These age ranges overlap; they are guides for organizing the menu, not strict limits. Older students should see tools for their subjects rather than a child-focused launcher.

Do not install every candidate by default. Confirm age range, lesson needs, offline requirements, and storage budget, then resolve the exact XBPS dependency closure and installed/download sizes. Keep online-only and large subject tools optional where a native package or school-provided web service is more suitable.

Edition experience

Provide a Pepvoid Education welcome center and XFCE menu with age pathways (Early years, Primary, Lower secondary, Upper secondary) and subject groups (Read and write, Mathematics, Science, Create, Computing, Teacher resources). Keep one predictable menu structure across the whole age range. Each entry should state its age/subject fit, whether it works offline, and where student work is saved. Teacher resources should include a short offline guide for classroom setup, accounts, printers, Wi-Fi, language, accessibility, updating, and saving student work. Avoid claiming curriculum alignment without review by local educators.

Offer configurable language packs rather than installing every locale. Start with Portuguese (Portugal) and English, and keep the normal installer language selection available. Test screen readers, keyboard-only use, high contrast, scaling, and touch input where the selected applications support them.

Operations and support

Void Linux is rolling. For school use, publish the tested ISO date, package manifest, repository snapshot, upgrade instructions, and recovery path. Trial updates on a small group of machines before classroom rollout. Do not enable unattended system upgrades. The administrator updates an installed computer from the XFCE Terminal using the separate root password; the student account does not need sudo or membership in wheel:

su -
# enter the root password when prompted
xbps-install -Su

XBPS asks before applying the proposed transaction. If the transaction updates xbps itself, run xbps-install -Su once more to complete the remaining updates. Reboot after a kernel update. Keep this as an administrator-led task so staff can review the proposed package changes and choose a maintenance window. Plan a way to restore student files separately from the operating system; a reinstallable image alone is not a backup.

The school must choose who administers local accounts, software installs, network access, and updates. If centrally managed accounts, home directories, thin clients, a local content server, or PXE are required, design and test a separate server/client deployment track. Debian Edu is a useful reference for those network services, not a package list to copy into a workstation ISO.

Build and qualification steps

  1. Confirm student age range, device profile, language, internet/offline needs, printer needs, and whether an existing school identity service must work.

  2. Validate every proposed XBPS package against current repositories and calculate separate core and optional group sizes.

  3. Draft the x86_64 glibc Education preset using the tested XFCE desktop, Education-specific Calamares account policy, and existing Pepvoid visuals.

  4. Add the Education Center, curated welcome page, offline handbook, and selected language defaults. Keep admin/teacher tools opt-in and clearly identified.

  5. Test the Live session, firewall at boot, IPv4/IPv6 inbound blocking, installer, student and root authentication, package privilege denial, encrypted and unencrypted installation paths, boot unlock, updates, backup recovery, language packs, apps, printing, offline use, weak hardware, and accessibility in VMs and representative school devices.

  6. Pilot with teachers and students before calling the image school-ready.

The first preset draft is available as --preset education. It includes the small classroom core and installer security policy. Older/lower-secondary and upper-secondary tools are separate configs/software/education-*.json profiles that can be added with repeated -p options. Example:

sudo python3 cli.py x86_64 --preset education \\
  -p education-lower-secondary -p education-upper-secondary \\
  --mode real --output pepvoid-education-x86_64.iso

Older-computer profile

Keep XFCE as the friendly default and avoid shipping heavyweight tools that are not needed in every classroom. Start applications only on demand; do not enable background indexing, cloud sync, or classroom monitoring by default. Keep the base image to the desktop, browser, office suite, PDF tools, printing support, and a small set of core learning applications. Put larger science, coding, and creative applications in optional build groups so schools can omit them on older machines or install them when needed. Measure boot time, idle memory, storage use, and application responsiveness on the oldest supported classroom computer before setting minimum hardware requirements. Use LXQt only if those measurements show XFCE misses the school’s target and real users find LXQt equally straightforward.

References

  • Edubuntu describes a classroom desktop focused on educational software, language support, privacy, and older hardware.

  • Debian Edu / Skolelinux documents a school-network design with central accounts, storage, printers, and thin clients, illustrating why a workstation and a school server are separate work.

  • GCompris documents its activities and age range; its administration handbook covers configuration for educational use.

  • Tux Paint describes its classroom use and target age.

  • Scratch on Flathub identifies the package as community-maintained and unverified.